[PFA 2/n] Support PFA functionality #20848

arnaud-lb · 2026-01-06T12:02:28Z

RFC: https://wiki.php.net/rfc/partial_function_application_v2

This follows #20717. This implements most of the RFC, except PFAs in constant expressions, and some optimization.

I wanted to split this PR more, but I didn't find a way to achieve this that makes sense.

A partial application is compiled to the usual sequence of function call
opcodes (INIT_FCALL, SEND_VAR, etc), but the sequence ends with a
CALLABLE_CONVERT_PARTIAL opcode instead of DO_FCALL, similarly to
first class callables. Placeholders are compiled to SEND_PLACEHOLDER opcodes:

$f = f($a, ?)

0001 INIT_FCALL f
0002 SEND_VAR CV($a)
0003 SEND_PLACEHOLDER
0004 CV($f) = CALLABLE_CONVERT_PARTIAL

SEND_PLACEHOLDER sets the argument slot type to _IS_PLACEHOLDER.

CALLABLE_CONVERT_PARTIAL uses the information available on the stack to
create a Closure and return it, consuming the stack frame in the process
like an internal function call.

We create the Closure by generating the relevant AST and compiling it to an
op_array.

The op_array is cached in the Opcache SHM and inline caches. The SHM key is prefixed with pfa:// to avoid any collision with actual files. When Opcache is disabled, we cache PFA op_arrays a global hash table. This is mainly useful for polymorphic PFAs, as the inline cache stores only a single entry.

TimWolla

Looked at 43/143 files with a mix of tests and C code.

Zend/zend_execute.c

TimWolla · 2026-01-07T11:23:04Z

Zend/tests/partial_application/errors_004.phpt

+
+?>
+--EXPECTF--
+Fatal error: Uncaught ArgumentCountError: f(): Argument #2 ($b) not passed in %s:6


Is it possible to improve the error message here to make it clear that this is happening during partial application?

This is not specific to partials: https://3v4l.org/biQNc

TimWolla · 2026-01-07T11:25:06Z

Zend/tests/partial_application/errors_005.phpt

+
+?>
+--EXPECT--
+ArgumentCountError: Closure::__invoke(): Argument #3 ($c) must be passed explicitly, because the default value is not known


As a user the error message reads odd, because stating that the default value is “unknown” implies that it is unclear whether there is one. If this is a technical restriction this should be rephrased to something like “cannot be determined for Closures” or something like that.

This error is not specific to partials or Closures: https://3v4l.org/Kl9M1

It is thrown when a parameter with position n < func_num_args() is not specified, and has a default value of UNKNOWN, like here:

php-src/ext/standard/basic_functions.stub.php

Line 1689 in 643cf62

function array_keys(array $array, mixed $filter_value = UNKNOWN, bool $strict = false): array {}

The reason it can happen is that functions assume that all arguments bellow func_num_args() are specified, but due to named args it's not always the case. So the engine fills the unspecified args bellow func_num_args() with their default value, but that's not possible with UNKNOWN.

Closure::__invoke() is a special case of this, as the default value is always unknown for this function (this affects only calling __invoke() explicitly).

I'm realizing that in the context of PFAs, we could probably avoid this by making placeholders without a default value required. I can look at this in a separate PR after this one.

Zend/tests/partial_application/magic_003.phpt

Zend/tests/partial_application/rfc_examples_incompatible_functions.phpt

Zend/zend_ast.c

TimWolla

74/144

Zend/tests/partial_application/non_dynamic_call_funcs.phpt

TimWolla · 2026-01-08T08:31:08Z

Zend/tests/partial_application/recorded_warnings.phpt

+
+Deprecated: Using "_" as a type name is deprecated since 8.4 in %s on line 5


I think this error message being emitted here is not great, because this is not actionable by the user who have written the PFA call (it can only be fixed by the author of the function being called).

Indeed.

Possible alternative ways to handle these errors:

Prefix errors with "During compilation of partial application:"

Discard non-fatal errors emitted during compilation of PFAs

Implement workarounds to avoid emitting any error

The second one seems to be the most sensible, as the errors are actually related to the function being called.

Zend/tests/partial_application/references_001.phpt

Zend/tests/partial_application/references_002.phpt

Zend/tests/partial_application/rfc_examples_debug.phpt

Zend/tests/partial_application/statics_002.phpt

Zend/tests/partial_application/statics_003.phpt

Zend/tests/partial_application/variation_invoke_001.phpt

Zend/tests/partial_application/variation_ex_001.phpt

TimWolla · 2026-01-08T08:41:12Z

Zend/tests/partial_application/variation_scope_001.phpt

I can't imagine what else than Foo would be returned for get_called_class(). Should this test involve inheritance?

Yes, this is just testing basic functionality. That get_called_class() works as expected is obvious with the current implementation, but may not have been with the previous one where the call was made in a more custom way.

Zend/tests/partial_application/rebinding_001.phpt

Zend/tests/partial_application/variation_call_001.phpt

Zend/zend_compile.c

TimWolla

At 100/146 files now. Looked at a majority (but not yet all of the tests). Only looked at the C files with a "small" number of changes, since I can only mark files as reviewed in a binary fashion and preferred getting as many files collapsed as possible.

Zend/tests/partial_application/variation_closure_001.phpt

ext/opcache/ZendAccelerator.c

TimWolla · 2026-01-15T22:29:10Z

Zend/zend_object_handlers.c

 	func->num_args = 0;
 	func->required_num_args = 0;
-	func->arg_info = (zend_arg_info *) arg_info;
+	func->arg_info = zend_call_trampoline_arginfo;


Is this a pre-existing bug? This should be spun out into a separate PR then.

I stumbled over this part of the diff for a while, since I didn't see where you introduced zend_call_trampoline_arginfo until I realized this is not new.

This is an oversight of #19022
I'm fixing this here: #20951

TimWolla

Did a first pass at zend_partial.c

Zend/zend_partial.c

TimWolla · 2026-01-15T22:36:16Z

Zend/zend_partial.c

+	return SUCCESS;
+}
+
+static bool zp_name_exists(zend_string **names, uint32_t num_names, zend_string *name)


Suggested change

static bool zp_name_exists(zend_string **names, uint32_t num_names, zend_string *name)

static bool zp_name_exists(const zend_string **names, uint32_t num_names, const zend_string *name)

Constifying to make Gina happy.

I don't think we can constify names in this case, as C doesn't allow the conversion from zend_string** to const zend_string** or const zend_string * const *.

Zend/zend_partial.c

TimWolla · 2026-01-15T22:56:41Z

Zend/zend_partial.c

+	}
+}
+
+static bool zp_is_power_of_two(uint32_t x)


Suggested change

static bool zp_is_power_of_two(uint32_t x)

static inline bool zp_is_power_of_two(uint32_t x)

FWIW: This is in C23 as stdc_has_single_bit_*() and could possibly be polyfilled in zend_portability.h.

It's tricky, as there is no u32 variant of stdc_has_single_bit_*(), and the generic macro stdc_has_single_bit() can not be polyfilled with purely standard code.

We could introduce a stdc_has_single_bit_u32() but then it's not really a polyfill. We could introduce a zend_is_power_of_two_u32() or zend_has_single_bit_u32().

TimWolla · 2026-01-15T23:02:47Z

Zend/zend_partial.c

+}
+
+/* Can not use zend_argument_error() as the function is not on the stack */
+static zend_never_inline ZEND_COLD void zp_argument_error(zend_class_entry *error_ce,


This would possibly also be useful for the new TYPE_ASSERT OPcode from my array_map() optimization PR.

Zend/zend_partial.c

TimWolla · 2026-01-15T23:06:10Z

Zend/zend_partial.c

+						default_value_ast, attributes_ast, NULL, NULL);
+
+			} else if (!Z_ISUNDEF(argv[offset])) {
+				// TODO: If the pre-bound parameter is a literal, it can be a


Yes this is the optimization I wanted to implement separately from this PR

Name is "arguments" in documentation: https://www.php.net/__call#language.oop5.overloading.methods

RFC: https://wiki.php.net/rfc/partial_function_application_v2 Co-authored-by: Joe Watkins <[email protected]>

* Fix zend_call_trampoline_arginfo arg name Name is "arguments" in documentation: https://www.php.net/__call#language.oop5.overloading.methods * Use zend_call_trampoline_arginfo in zend_get_call_trampoline_func() * Copy the original arg_info in zend_closure_from_frame None of these changes are observable, but this is cleaner, and this becomes observable in GH-20848. Closes GH-20951

github-actions bot added Category: Build System Category: Engine Extension: opcache Category: Optimizer ABI break labels Jan 6, 2026

TimWolla added the RFC label Jan 6, 2026

TimWolla reviewed Jan 7, 2026

View reviewed changes

arnaud-lb mentioned this pull request Jan 7, 2026

Introduce zend_ast_call_get_args() #20859

Merged

TimWolla reviewed Jan 8, 2026

View reviewed changes

arnaud-lb force-pushed the partials-v2-gen branch from 0b7a4a5 to 2cf2ae1 Compare January 8, 2026 11:32

arnaud-lb marked this pull request as ready for review January 13, 2026 15:13

arnaud-lb requested a review from dstogov as a code owner January 13, 2026 15:13

TimWolla reviewed Jan 15, 2026

View reviewed changes

arnaud-lb mentioned this pull request Jan 15, 2026

zend_compile: Optimize array_map() with callable convert callback into foreach #20934

Open

TimWolla reviewed Jan 15, 2026

View reviewed changes

arnaud-lb mentioned this pull request Jan 16, 2026

Followup GH-19022 #20951

Merged

arnaud-lb force-pushed the partials-v2-gen branch from f1d1263 to 9023d96 Compare January 16, 2026 12:01

arnaud-lb and others added 12 commits January 16, 2026 13:27

Fix zend_call_trampoline_arginfo arg name

ff9fe8f

Name is "arguments" in documentation: https://www.php.net/__call#language.oop5.overloading.methods

Use zend_call_trampoline_arginfo in zend_get_call_trampoline_func()

83dd506

Copy the original arg_info in zend_closure_from_frame

4b139e7

Partial application

2f7c87d

RFC: https://wiki.php.net/rfc/partial_function_application_v2 Co-authored-by: Joe Watkins <[email protected]>

Remove unnecessary change

7df2a96

Skip preload test on Windows

0d5bc0c

Comments

0b8ea23

Improve type coherency

164c1a7

Clarify

b23f9ab

Useless memset

e1c7246

Move include

6fdcba2

Rename tests

9df4020

arnaud-lb added 18 commits January 16, 2026 13:27

Fix test

04d35e2

Better type

e352d88

Generated file

34f44f3

Consistency

537dc43

Fix test name

1c4e17d

Improve tests

7b01395

Improve tests

082fc7d

Improve tests

1cda71f

Update comment, add tests

eb7985a

Improve test

bf977de

Avoid void cast

8c4dfd5

Fix tests

123d60a

constify

dfdc542

inline

3e9ea21

Useless condition

3f42992

const

ab6571d

Simplify

0eda184

fix build

8f12cdd

arnaud-lb force-pushed the partials-v2-gen branch from bfe4de7 to 8f12cdd Compare January 16, 2026 12:37


		Deprecated: Using "_" as a type name is deprecated since 8.4 in %s on line 5

	static bool zp_name_exists(zend_string *names, uint32_t num_names, zend_string name)
	static bool zp_name_exists(const zend_string *names, uint32_t num_names, const zend_string name)

	static bool zp_is_power_of_two(uint32_t x)
	static inline bool zp_is_power_of_two(uint32_t x)

[PFA 2/n] Support PFA functionality #20848

Are you sure you want to change the base?

[PFA 2/n] Support PFA functionality #20848

Uh oh!

Conversation

arnaud-lb commented Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TimWolla left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TimWolla left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

arnaud-lb Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TimWolla left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TimWolla left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

arnaud-lb commented Jan 6, 2026 •

edited

Loading

arnaud-lb Jan 8, 2026 •

edited

Loading